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1. Introduzione 


Il presente articolo nasce da una serie di riflessioni e considerazioni sorte 
durante la ristrutturazione del Sistema informativo per la terminologia giuridi- 
ca — bistro (<http://bistro.eurac.edu>). Si tratta di un applicativo online su cui 
vengono caricati i dati provenienti da una banca dati terminologica multilingue 
operante su SDL MultiTerm. Il vecchio sistema, risalente al 2001 e basato su un 
linguaggio e una tecnologia ormai superati, era diventato con il tempo difficile 
da gestire in termini di aggiornamento, manutenzione, filtraggio dei dati, fru- 
ibilità e visualizzazione delle informazioni. A ciò si aggiungevano un modulo 
di ricerca abbastanza limitato e una consultazione non intuitiva. Inoltre, risa- 
lendo le prime schede terminologiche al 1994 e date le limitazioni dei sistemi 
di gestione terminologica di quegli anni, il patrimonio terminologico esisten- 
te? non risultava omogeneo, soprattutto a livello delle picklist e delle categorie, 
conteneva doppioni ed era presente una certa ridondanza. 


Le prime schede terminologiche furono elaborate con MultiTerm 95. All'epoca questo sistema era 
innovativo e all'avanguardia, tuttavia presentava delle limitazioni. Ad esempio, la definizione della 
banca dati poteva contenere fino ad un massimo di 62 campi testuali e 30 campi attributivi, le cui 
picklist potevano raggiungere un massimo di 1042 caratteri (TRADOS GmbH 1995-1997, 43). 

Il patrimonio terminologico, in lingua italiana, tedesca e ladina, conta attualmente (2020- 
01-30) circa 21.600 schede, di cui ca. 13.200 sono pubblicate in bistro. 
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Si era perciò reso necessario pensare ad un nuovo sistema che fosse in gra- 
do di rispondere alle diverse esigenze degli utenti. Questi comprendono sia i 
collaboratori dell’Istituto di linguistica applicata di Eurac Research (es. ag- 
giornamento dei dati più agevole) sia gli utenti esterni, siano essi professionisti 
del mondo del diritto, traduttori, studenti o altre persone che necessitano di un 
valido supporto alla comprensione e traduzione di testi e documenti giuridici. 

La check-list, oggetto del presente contributo, è frutto dell’intenso lavoro 
svolto durante i tre anni di progettazione e riprogrammazione del nuovo bistro. 
È pensata come punto di partenza e riflessione perl’ideazione e strutturazione 
di prodotti terminologici, quali strumenti di «organizzazione e trasmissione di 
conoscenze specialistiche» (Agrario, Castagnoli 2010, 121). L'obiettivo è forni- 
re un aiuto per individuare il fabbisogno e, al contempo, meglio comprendere le 
scelte di fondo che è opportuno compiere già in fase di pianificazione. 


2. Riflessioni iniziali 


Che si disponga o meno di dati terminologici, è fondamentale avere piena 
coscienza dello strumento che si vuole sviluppare. Non sono pochi i casi in cui 
vengono commessi degli errori già durante la sua concezione, tali da richiede- 
re, in un secondo tempo, delle modifiche importanti, comportando non solo 
una perdita di tempo, ma spesso anche un aumento dei costi. In questo senso 
un'analisi ponderata di elementi primari, quali, ad esempio, fabbisogno, desti- 
natari, livelli di qualità, requisiti tecnici, caratteristiche delle singole funzioni, 
possibili criticità, può agevolare un inserimento corretto e strutturato dei dati 
e, conseguentemente, favorire un utilizzo efficace ed efficiente del prodotto da 
parte degli utenti. 

Il livello di qualità che si vuole dare all’informazione terminologica e alla 
sua trasmissione può, infatti, essere valorizzato da una struttura ragionata, fun- 
zionale e flessibile. Un lavoro completo e valido può invece essere sminuito da 
una struttura rigida e vincolante (Agrario, Castagnoli 2010, 138). 

Realizzare strumenti terminologici richiede innanzitutto una profonda cono- 
scenza della disciplina e delle pratiche terminologiche. In questo senso le norme 
ISO ci vengono in soccorso. Ad esempio, la ISO 1087 definisce il vocabolario 
fondamentale perla teoria e la pratica dell’attività terminologica, mentre la ISO 
704 stabilisce principi e metodi del lavoro terminologico. 

I prodotti terminologici, nello specifico le banche dati terminologiche, pre- 
sentano una struttura logica che si compone di più livelli su cui vengono posi- 
zionate le categorie terminologiche. Questi livelli sono descritti nelle norme 
ISO 26162-1 e ISO 30042: 

e concept level: è il livello in cui inserire i dati amministrativi relativi al con- 
cetto (es. progetto, cliente) e informazioni terminologiche non linguistiche 
(es. un grafico); 

e language level: è il livello in cui confluiscono tutte le denominazioni relative 
ad un dato concetto in una data lingua; può anche contenere informazioni 
specifiche (es. definizione) (Drewer e Schmitz 2017:134 ss.; ISO 26162-1); 
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e term level: èil livello in cui vengono inserite tutte le informazioni pertinenti 
ad una data denominazione. È sicuramente il livello più corposo in quanto 
si costituisce di categorie terminologiche di carattere testuale (es. definizio- 
ne, contesto, fonte, etichette contestuali) e attributivo (es. grammatica, uso 
geografico, status). 


L'informazione terminologica viene dunque trattata all’interno di specifi- 
che categorie. La loro tipologia dipende essenzialmente dal tipo di utenza, dal 
dominio di indagine e dalle finalità del lavoro. A prescindere dal tipo di catego- 
ria, se testuale o attributiva, è fondamentale attenersi ai principi di elementarità 
e granularità (ISO 26162-1; Pulitano 2010; Drewer, Schmitz 2017, 126; Ralli, 
Andreatta 2018, 31). In base al primo, le categorie terminologiche possono con- 
tenere un solo tipo di informazione. Ad esempio, in una banca dati giuridica, 
che comprende informazioni su più ordinamenti giuridici, il campo destinato a 
contenere definizioni pertinenti all’ordinamento giuridico italiano non dovreb- 
be contenere definizioni relative ad altri ordinamenti contemplati dalla banca 
dati. In base invece al secondo principio, ogni categoria deve essere definita con 
il maggior dettaglio possibile. Al riguardo la ISO 26162-1 cita come esempio le 
informazioni grammaticali, secondo cui i valori relativi al genere e al numero 
dovrebbero confluire in due categorie separate. 

Altro elemento di cui, infine, tenere conto è l’autonomia delle denomina- 
zioni: tutti i termini, che si riferiscono allo stesso concetto (quindi sinonimi e 
varianti), sono considerati sotto-unità e, pertanto, possono essere descritti con 
lo stesso set di categorie terminologiche utilizzato per la descrizione del termi- 
ne principale (ISO 26162-1). 


3. La check-list 


La check-list si pone come un insieme di criteri pensati come punto di par- 
tenza e riflessione per l'ideazione e strutturazione di strumenti terminologici, 
siano essi banche dati o applicativi su cui vengono caricati dati provenienti da 
sistemi di gestione terminologica. 

Si compone di cinque parti: la prima è di carattere generale; la seconda è de- 
dicata ai dati, cioè l’informazione terminologica, e alla loro tipologia che riveste 
un ruolo particolarmente importante; la terza parte è focalizzata sulle lingue di 
lavoro, mentre la quarta verte sulle fonti bibliografiche; la quinta parte si con- 
clude con delle considerazioni sulla messa online dello strumento e sulla rela- 
tiva gestione e manutenzione. 


3.1 Parte generale 


La prima parte, di carattere generale, è volta ad individuare importanti punti 
di base che influiscono sostanzialmente, ad esempio, sullo sviluppo dello stru- 
mento, sulla struttura, ecc. In questa fase ci si concentra sulla destinazione della 
risorsa terminologica, il gruppo di utenza, gli obiettivi, le funzioni e i domini. 
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Figura 1 - Parte generale 


In riferimento alla destinazione dello strumento terminologico è fonda- 
mentale stabilire se è per uso interno o esterno o entrambi, quindi sia per uso 
interno che esterno. 

Per quanto riguarda il gruppo di utenza, è importante precisare se si tratta, 
ad esempio, di esperti del settore, traduttori, redattori, studenti o di utenti non 
esperti. La loro tipologia condiziona profondamente quali informazioni trattare 
e come presentarle. È pertanto opportuno chiedersi, per esempio, quali categorie 
terminologiche prevedere in base al tipo di utenza. È inoltre di notevole rilevan- 
za definire se si tratta di un gruppo di utenti rientranti in una stessa categoria o in 
categorie differenti. È pertanto necessario stabilire se lo strumento si rivolgerà a 
un pubblico abbastanza omogeneo o, invece, piuttosto eterogeneo. Nel caso in cui 
il prodotto fosse destinato a un'utenza diversificata, si profilano due possibilità: 
e strutturare le schede, fin dall’inizio, in funzione di un utente modello e, 

quindi, decidere quali categorie e valori debbano essere presenti o meno per 

soddisfarne le esigenze; 

e predisporre più categorie, laddove alcune saranno interessanti per un certo 
gruppo di destinatari, altre meno e viceversa. In questo caso è da valutare 
se, offrendo ai vari utenti la possibilità di filtrare i risultati e/o impostare dei 
criteri di ricerca, si riesca a soddisfare le diverse esigenze. 


In questa prima fase è inoltre fondamentale stabilire gli obiettivi e la funzio- 
ne dello strumento. Occorre, per esempio, considerare se lo strumento è conce- 
pito per agevolare la comunicazione transfrontaliera, la comunicazione entro i 
confini nazionali, la comunicazione all’interno di una organizzazione o impresa 
e/o se è ideato per supportare la comunicazione, la traduzione o la redazione in 
generale. Si tenga presente che si possono avere diversi obiettivi per uno stesso 
strumento e che tutte queste ipotesi possono far riferimento aduna o più lingue. 

In merito alla funzione è opportuno chiedersi se lo strumento è pensato, ad 
esempio, per favorire la comprensione dei concetti e dei testi e/o fornire un aiu- 
to per la produzione di testi nella madrelingua o nella lingua straniera o la tra- 
duzione in una direzione linguistica o nell’altra (Bergenholtz, Tarp 2010, 31). 

Importante è, infine, il dominio. Alcuni settori hanno esigenze particola- 
ri, come ad esempio il diritto, in cui il linguaggio giuridico è fortemente lega- 
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to all’ordinamento giuridico che lo ha prodotto, o settori tecnici dove non è da 
escludere la presenza di formule. 


3.2 I dati 


La seconda parte della check-list è dedicata all’informazione terminologica e 
alla tipologia dei dati. In questo contesto la prima domanda da porsi è senz'altro 
se lo strumento viene ‘riempito’ ex novo o se è già presente un data set che dovrà 
essere integrato completamente o solo in parte nel nuovo strumento. 


e oli 
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Figura 2 - I dati 


3.2.1 Patrimonio dati assente 


Se non si dispone ancora di una base di dati, si profilano due considerazioni. 
Da un lato, la situazione può ritenersi semplice, in quanto non si è necessaria- 
mente vincolati a decisioni prese in precedenza e si può, quindi, definire tutto 
sin da principio. Dall’altro, la situazione può palesarsi più delicata. Potrebbe in- 
fatti risultare necessario prendere decisioni nuove senza talvolta conoscere tutte 
le specificità delle informazioni e delle eventuali criticità a cui si dovrebbe far 
fronte e che, in presenza di un data set esistente, si sono invece già affrontate e 
di cui, quindi, si può tenere conto in questi ragionamenti iniziali. 

La parte della check-list relativa ai dati comprende, ad esempio, delle consi- 
derazioni sulla loro gestione ed eventuale scambio, sull’approccio da adottare 
per la presentazione delle informazioni e sulla loro tipologia. 
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In merito alla gestione è da ponderare se il nuovo strumento sarà gestito a 
livello centrale o locale. Pensare a quale metodo adottare ha l’obiettivo di esplo- 
rare se sarà seguito un approccio onomasiologico o semasiologico, se sarà orien- 
tato alla traduzione o meno o se, invece, sarà necessario applicare più approcci. 

Altre domande da porsi riguardano quindi quali informazioni accogliere e 
quali presentare all’utente: solo termini (eventualmente con sinonimi e varian- 
ti) o termini corredati da informazioni aggiuntive come definizioni, contesti, 
note, ecc. Già in questa fase è opportuno stabilire se il data set includerà anche 
altri tipi di dati (es. fraseologismi) che potrebbero richiedere un approccio spe- 
cifico, ovvero diverso da quello adottato per gli altri dati. 

Mentre contesti e altre informazioni, come ad esempio la grammatica, sono 
facili da collocare nella struttura di una banca dati, la definizione richiede qual- 
che riflessione in più. Prima di tutto occorre chiedersi su quale livello collocarla, 
e cioè se sul livello del concetto, della lingua o del termine principale (Drewer, 
Schmitz 2017, 134 ss.; ISO 26162-1). In uno strumento che comprende più lin- 
gue è inoltre da decidere se definire il concetto solamente nella lingua pivot o se 
mettere una definizione per ogni lingua indagata. Anche in riferimento a even- 
tuali note sarà da valutare su quale livello o livelli collocarle e stabilire se sono 
note per l'utente finale esterno o solo per l’uso interno e/o per chi elabora i dati. 

Anche per la dicitura delle categorie terminologiche è da considerare se si 
vuole adottare una lingua pivot per tutte le categorie, a prescindere dal numero di 
lingue che saranno presenti nello strumento finale, o definire le singole categorie 
e le eventuali picklist ad esse relative, secondo la lingua a cui esse si riferiscono. 

Con riguardo alla struttura e alle categorie da includere, oltre al fabbisogno 
dell’utente esterno è anche opportuno tenere conto di quello interno, nello 
specifico del personale che dovrà ‘riempire’ la banca dati: se la struttura è trop- 
po complessa, può diminuire la motivazione di inserire dati nei campi richiesti 
(Drewer, Schmitz 2017, 128). Se una struttura è troppo libera, possono finire 
nei campi delle informazioni non adatte alla categoria. Se invece è troppo ri- 
gida, ad esempio perché presenti molti campi obbligatori o non predisposta a 
eventuali aggiunte di nuove voci, chi inserisce può riscontrare delle situazioni 
in cui è difficile assegnare una specifica informazione ad un valore preimposta- 
to. Per esempio, può succedere che possano mancare dei valori dalle picklist. In 
questo caso si prospettano due scenari: 1) il campo non è obbligatorio, per cui 
si può anche scegliere di non selezionare alcuna voce della picklist; 2) il campo 
è obbligatorio, pertanto è necessario selezionare un valore qualsiasi fra quelli a 
disposizione, sebbene sbagliato. Ciò potrebbe quindi generare dati incongruenti 
e informazioni non sempre del tutto corrette. 

Inoltre è da riflettere quali categorie devono essere di genere testuale (open 
data categories), ossia quelle in cui è possibile inserire del testo libero, e quali di 
genere attributivo in forma di picklist, (closed data categories), dove la persona che 
inserisce i dati ha a disposizione un elenco chiuso di elementi tra cui scegliere (ISO 
26162-1). Quest’ultime sono da preferire poiché favoriscono un inserimento più 
veloce e ‘pulito’, permettono una maggiore uniformità dei dati e aiutano ad evita- 
re degli errori (per es. che vengano inseriti dei dati nel campo sbagliato) (Drewer, 
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Schmitz 2017, 138). Naturalmente non per tutte le informazioni sono possibili 
delle closed data categories, tra gli esempi più evidenti definizioni e contesti. 

In questa fase è anche da stabilire se è previsto uno scambio di dati, per esem- 
pio tra due o più istituzioni o uffici, e con quale modalità i dati saranno scambiati. 


3.2.2 Patrimonio dati presente 


In presenza di un patrimonio già esistente, si operano le stesse riflessioni 
descritte nella sezione precedente (3.2.1.). Tuttavia, la presenza di dati ha sen- 
za dubbio un grande impatto sulla concezione del nuovo strumento e richiede 
pertanto ulteriori considerazioni. 

Molto dipende da quali dati sono presenti e in che forma. Bisogna quindi te- 
ner conto di fattori come, per esempio, la gestione dei dati in passato: se erano 
elaborati su iniziativa del singolo e amministrati da differenti postazioni, come 
singoli uffici, e quindi si tratta di patrimoni separati, o se invece erano gestiti 
centralmente con possibilità per tutti di accedere allo stesso patrimonio di dati. 

A questo si collega la questione sull’approccio adottato per l’elaborazione dei 
dati: è stato adottato un unico approccio (es. onomasiologico, semasiologico) o 
è stato impiegato un mix di approcci? Nel primo caso bisognerà considerare se 
mantenere lo stesso metodo anche per il futuro; nel secondo caso sarà necessa- 
rio valutare quale tra quelli impiegati in passato sarà opportuno scegliere e, di 
conseguenza, quali modifiche saranno richieste per adattare il patrimonio o i 
singoli data set al nuovo approccio che si intende seguire in futuro. 

In relazione alla tipologia dei dati, valgono le stesse riflessioni di cui sopra 
(3.2.1.): se si tratta di soli termini, se con varianti e sinonimi, se i termini sono 
corredati da informazioni aggiuntive, come definizioni, note, ecc.; come sono 
organizzate le categorie e quali di queste si vogliono accogliere nel nuovo stru- 
mento; se mantenere la struttura o se, invece, ci sono elementi da cambiare. 

Un aspetto rilevante è senza dubbio anche il formato in cui sono disponibi- 
li i dati (es. formato MS Excel o Word, XML, formati supportati dai sistemi di 
gestione della terminologia, come il TBX) e se i dati sono presenti in formati 
diversi. Ne consegue la necessità di valutare quale formato è meglio usare per il 
nuovo strumento o anche solamente per importarvi i dati e, successivamente, 
quali misure prendere per uniformarli. 

Si deve inoltre tenere conto dei seguenti fattori: 

e seidati esistenti si presentano in modo uniforme o meno; 

e seci sono doppioni, soprattutto nel caso in cui i dati provengano da banche 
dati diverse o siano gestiti non centralmente; 

e seè stata adotta una lingua pivot per tutte le categorie o se invece quest’ul- 
time sono distinte a seconda delle lingue in cui è stata elaborata la scheda. 
Per esempio: i termini italiani avranno in questo caso categorie ed eventuali 
picklist in lingua italiana, i termini tedeschi saranno corredati da categorie 
ed eventuali picklist in lingua tedesca; 

e se è stato adottato il principio dell’elementarità e della granularità (cfr. 2) o se 
una categoria terminologica può contenere per esempio informazioni di vari tipi. 
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È, infine, da valutare se ci sarà o meno uno scambio di dati e in che modo 
saranno gestiti, se centralmente o localmente. Anche in questo caso valgono le 
stesse riflessioni descritte nella sezione precedente (3.2.1). 


3.3 Lingue di lavoro 


La terza parte della check-list verte sulle lingue di lavoro. 


Lingue di lavoro 


dati tipologia software 


Le lingue sono supportate 
dal software? 


I dati termimologici 
si riferiscono ad una 
lingua o più lingue? 


Si tratta di lingue 


con più varieta? 


metodo 


orientamento verso inclusione di più 
una varietà specifica varicta 


Figura 3 - Lingue di lavoro 


Conriguardo alle lingue è particolarmente importante sapere se i dati termi- 
nologici si riferiscono ad una lingua o più lingue. Inoltre, è interessante sapere 
se si tratta di lingue con più varietà (es. inglese americano, inglese britannico) 
e, in tal caso, se si decide di orientarsi su una varietà specifica o se si prevede di 
includere più varietà. Lavorando con più varietà linguistiche, seguono poi le ri- 
flessioni su come strutturare le informazioni perle diverse varietà, ovvero come 
indicare quali informazioni si riferiscono a quale varietà. Altrettanto importan- 
te è verificare se le lingue (ed eventuali varietà) sono supportate dal software. 

Infine, un altro aspetto che influisce sulla struttura e le categorie da aggiun- 
gere è se si prevede un’armonizzazione terminologica. Per esempio è da conside- 
rare quale categoria e relative voci predisporre per indicare lo stato nel workflow 
di armonizzazione, se si tratta di un termine nuovo aggiunto nella banca dati o 
approvato dall’organo di armonizzazione o altro. 


3.4 Fonti bibliografiche 


Essendo la documentazione dell’informazione terminologica un aspetto fon- 
damentale di qualsiasi lavoro terminologico (Arntz et al. 2014, 212 ss.; Drewer, 
Schmitz 2017, 53 ss.), nella maggior parte dei casi le informazioni saranno cor- 
redate da fonti bibliografiche. È quindi importante riflettere su come gestire le 
fonti e dove catalogarle. La quarta parte della check-list verte pertanto sulle fonti 
bibliografiche, ad esempio in che forma queste dovranno essere citate e catalo- 
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gate o, in presenza di un patrimonio terminologico già esistente, in quale forma 
e modo tali fonti sono già state citate e catalogate. 


Fonti bibliografiche 


data sgt assente data set presente 


Le informazioni sono corredate 
da fonti bibliografiche? 


Le fonti bibliografiche saranno corredate 
da fonti bibliografiche? 
Le fonti bibliografiche saranno catalogate? Le fomi bibliografiche sono catalogate? 


Dove saranno catalogate le fonti 
bibliografiche? 


Dove sono catalogate le fonti 


bibliografiche (es. file xis/xksx; doc\docx...)}? 


Le fonti bibliografiche dovranno essere 
cliccabili/ consultabili anche dall'esterno 
(es. online)? 


Le fonti bibliografiche sono citate in modo 
uniforme? 


Figura 4 - Fonti bibliografiche 


Se sono già presenti dati terminologici, si deve considerare se questi sono già 
corredati da fonti bibliografiche. Se sì, va verificato se sono catalogate, dove sono 
salvate e in quale formato o formati. È inoltre da valutare se mantenere lo stes- 
so metodo di citazione o, in caso fossero presenti più forme di citazione, quale 
scegliere e, conseguentemente, come uniformarle. Per diverse categorie di fonti 
può essere anche necessario prevedere diversi tipi di informazioni da aggiungere 
o modi di citazione da adottare. Si pensi, ad esempio, a manuali e siti internet. 

È, infine, da riflettere se o come gli utenti finali potranno accedere alle infor- 
mazioni complete sulle singole fonti bibliografiche (per esempio, tramite click 
sulla sigla o indicazione breve della fonte). 


3.5 Pubblicazione online e gestione 


La quinta e ultima parte della check-list è dedicata alla pubblicazione onli- 
ne, la relativa gestione e la manutenzione dello strumento. 

Innanzitutto è da definire cosa mettere a disposizione dell’utente finale. Nel- 
lo specifico è da stabilire se tutte le informazioni elaborate saranno visibili an- 
che all’esterno o se certe categorie non saranno visibili, in quanto di rilevanza 
prettamente interna. 

Altre domande da porsi sono ad esempio: 

e che tipo di ricerca potrà svolgere l’utente (es. solo semplice, semplice e 
avanzata); 

e quali parametri possono essere interessanti per la ricerca avanzata; 

e  sel’utente dovrà selezionare sempre (anche nella ricerca semplice) una lin- 
gua di partenza; 
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e sel’utente dovrà selezionare una direzione linguistica e se, in questo caso, si 
possono selezionare anche più lingue di arrivo; 

e in che ordine i risultati della ricerca dovranno essere visualizzati; 

e seľutente potrà filtrare i risultati e quali saranno i criteri di filtraggio; 

e selefonti bibliografiche dovranno essere cliccabili e quali informazioni ver- 
ranno presentate; 

« se potrebbero essere necessari dei contenuti espandibili; 

e sesidesidera un'interazione con l’utente e, in caso, in che forma e chi sareb- 
be addetto a rispondere alle richieste degli utenti; 

e seilpatrimonio terminologico sarà aggiornato regolarmente e chi si occu- 
perà di caricare periodicamente i (nuovi) dati online. 


4. Conclusioni 


Dai lavori svolti per riprogrammare bistro e, con esso, rivedere la banca dati 
terminologica operante su SDL MultiTerm, è nata questa check-list. Natural- 
mente non la si può considerare esaustiva, cerca tuttavia di fornire una guida 
sugli aspetti ed elementi di cui occorre tenere conto se si decide di sviluppare 
uno strumento terminologico, sia esso una banca dati terminologica interna o 
un applicativo online. Ciò per evitare il più possibile degli ‘errori’ ed eventua- 
li modifiche, che potrebbero risultare in seguito necessari a causa delle scarse 
riflessioni nella fase di concezione dello strumento terminologico, con conse- 
guente perdita in termini di tempo e costi. 

Abbiamo visto che sono, infatti, numerosi i fattori di cui dover tenere con- 
to già nelle fasi di concezione e pianificazione dello strumento: dagli obiettivi 
e i destinatari fino alle condizioni base per lo sviluppo e le possibili criticità. 
Un’attenta analisi dei dati e del fabbisogno consente di definire detti fattori e, 
al contempo, di individuare le funzioni a cui dovrebbe assolvere lo strumento, 
nonché le modalità di ricerca e di visualizzazione delle informazioni. Affinché 
la qualità dell’informazione possa essere valorizzata al meglio è, quindi, fonda- 
mentale che ci sia una certa coerenza fra quelli che sono il gruppo di utenza, le 
caratteristiche del dominio, le funzioni e gli obiettivi dello strumento con le ca- 
tegorie terminologiche e le informazioni che vengono poi messe a disposizione. 

Va tuttavia tenuto bene a mente che uno strumento terminologico non è 
mai un prodotto finito. Bisogna pertanto sempre pensare a lungo termine e fa- 
re in modo che tale strumento presenti una certa flessibilità, cioè che sia aperto 
a eventuali modifiche e/o aggiunte anche in futuro. 
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